I had a couple of ideas about the g_free problem, but haven't had a chance to try them yet.

1. Try and resolve the g_free relative virtual address by inspecting the qemu binary, add that to the base address that qemu is loaded at and cast it to a fptr and use that. Not sure if I'll be able to do this, will require sufficient debug info in qemu.
2. I think that on windows glib ends up just calling the 'normal' free function you get from Windows. If so, we might get away with calling that directly. If this worked, we would be relying on glib never changing internal details of his it mallocs and frees on windows.

Have had a quick play with this...

I had a couple of ideas about the g_free problem, but haven't had a chance to try them yet.

1. Try and resolve the g_free relative virtual address by inspecting the qemu binary, add that to the base address that qemu is loaded at and cast it to a fptr and use that. Not sure if I'll be able to do this, will require sufficient debug info in qemu.

This is a non-starter, qemu as downloaded doesn't have debug symbols:

2. I think that on windows glib ends up just calling the 'normal' free function you get from Windows. If so, we might get away with calling that directly. If this worked, we would be relying on glib never changing internal details of his it mallocs and frees on windows.
   This could work:

#[cfg(windows)]
unsafe fn g_free(mem: *mut c_void){
    //HACK: We would really like to call g_free in the qemu binary here
    //but we can't, because windows doesn't export symbols unless you explicitly export them
    //and qemu doesn't export g_free.

    //Instead we'll rely on glib only using stdlib.h's malloc/free and call it directly.
    //On glib docs, it says
    //> Since GLib 2.46 g_malloc() is hardcoded to always use the system malloc implementation.
    //So should be safe to call free ourselves.
    unsafe {
        if !mem.is_null() {
            libc::free(mem);
        }
    }
}

Good enough for me, IMO better to make it work now than stress too much about it breaking in the future! Thanks for testing this out!

I know combining "fix CI" and "add a feature" in one PR is bad practice, but luckily this repo has 5 stars so I think I can get away with it for now. I'll merge this once I can get CI to work, I just checked and there's enough space so something else weird is going on. The built image is 30.2GB, well under the available space.

Getting there, Linux CI is working and what I'm trying to do for Windows CI is working locally :)

Alrighty, it's not much but we are now testing Linux & Windows plugins in CI so that's cool! Thanks for doing the heavy lifting @tocklime!